A wide variety of different types of computer applications are currently in use. Such computer applications often fall into three or more different categories. For instance, rich client applications are typically applications that run on a client device, such as a desktop computer or laptop computer. Other software applications include web-based applications in which a client interacts with a web-based device, such as a server using a web browser, in order to run the application. Still other software applications include mobile device applications. Mobile device applications might run on mobile devices, such as personal digital assistants (PDAs), telephones, handheld computers, etc.
In running a software application, a user typically wishes to perform one or more different tasks. As used herein, the term task means anything that a user wishes to do in the context of a given software application.
In order to allow users to accomplish the desired tasks, many current software applications provide a graphical user interface. The user executes one or more commands on the graphical user interface to accomplish a desired task. There are substantially three main ways by which people accomplish tasks using a graphical user interface, and they depend on how frequently the user performs a given task. For tasks that are performed frequently by the user, the user might learn or memorize the sequence of steps (or commands) required to perform the task with the graphical user interface. Also with frequently performed tasks, applications might expose the user interface elements for performing the most popular tasks prominently in the user interface.
A second group of tasks are those that are performed infrequently by the user. The user may typically browse the menus or tool bars displayed by the graphical user interface, in order to attempt to locate the user interface element that can be used to perform the desired task. Another way in which users perform infrequent tasks is to seek the help of other people to find out how to perform the task. In doing this, the user might go to a news group or simply ask another individual how to perform the task.
Finally, when the user does not remember how to perform the task, and cannot find out how to perform the task by asking others, users might typically invoke a help mechanism associated with the application. For instance, some applications are associated with help documentation stored on a client, or on a web site. The help documentation allows a user to search for a help topic that often explains what to do in order to accomplish a task that a user wishes to perform.
Of course, there are a number of problems associated with these types of current systems. Unless the user has the steps for performing a task memorized, it can be fairly cumbersome for the user to find out how to perform the task. Asking news groups or physically asking other persons how to perform a task takes a relatively large amount of time and thus reduces efficiency.
In addition, even where the user attempts to hunt through the user interface to find the user interface element necessary to accomplish the desired task, the user may encounter problems. For instance, in most graphical user interfaces, the features or elements associated with the graphical user interface are categorized under other elements. In other words, the user may go to the “File” drop down menu to look for a particular feature or element of the graphical user interface. The user may also go to the “Edit” drop down menu to look for another feature. Of course, if the sought after feature is under an unexpected drop down menu, this can result in frustration and extra time required for the user to find that feature.
Similarly, attempting to determine how to perform a task using help documentation often requires a fairly high level of knowledge about the task. For instance, some help documentation is simply an alphabetical listing of different tasks. This may be extremely unhelpful to a user who does not know the technical term for the task to be performed. By way of example, in one spreadsheet software application, adding rows and columns to a spreadsheet is performed using an “insert” command. Of course, it would take a user a fairly long time to track this command down, if the user was simply looking under the “add” commands in the help documentation.
Similarly, many help mechanisms provide information that is not useful in a given context. For instance, assume the user is in a word processing application which has no tables in it, but the user wishes to add a table. The help mechanism might typically be arranged with all information related to tables found in a plurality of different spots within the help documentation. Thus, the help documentation might include modifying existing tables, adding or deleting rows or columns from tables, and a wide variety of other information dealing with already-existing tables. Of course, since the user's document has no already-existing tables, this information is completely useless to the user. Yet, the user must sift through this information in order to identify the steps necessary to add a table.
The discussion above is merely provided for general background information and is not intended to be used as an aid in determining the scope of the claimed subject matter.
The discussion above is merely provided for general background information and is not intended to be used as an aid in determining the scope of the claimed subject matter.